\mysection{Verwendete Technologien}
\label{real:sec:technologien}
Um unser Konzept umzusetzen, mussten wir auch Entscheidungen über die
einzusetzenden Technologien treffen. Unter diesem Oberbegriff wollen wir hier
auch Programmiersprachen, Frameworks und Bibliotheken verstehen. Da unser
Konzept als Integration in \masp umgesetzt werden soll, wurden uns diese
Entscheidungen jedoch schon weitestgehend abgenommen. Wie genau uns die
Entscheidungen abgenommen bzw. erleichtert wurden, werden wir in den folgenden
Abschnitten, jeweils in Bezug auf die jeweilige Technologie, genauer erläutern.

\mysubsection{Java}
\label{real:subsec:java}
Als Programmiersprache setzen wir Java ein. \masp selbst ist eine Java-Web-App.
Deswegen ist es die logische Konsequenz, unsere Implementierung ebenfalls in
Java durchzuführen. So ist die nahtlose Integration unserer Klassen in \masp
gewährleistet.

\mysubsection{JAXB}
\label{real:subsec:jaxb}
In unserem Konzept ist vorgesehen, dass Nachrichtenquellen ihre
Nachrichtenkategorien registrieren können. Zudem sollen die Benutzer persönliche
Dringlichkeiten für die verschiedenen Auslieferungszeitpunkte einer
Nachrichtenkategorie angeben können. Um diese Daten persistent zu speichern,
gibt es verschiedene Möglichkeiten. Zum einen wären das Datenbanken in
unterschiedlichen Ausprägungen von relationalen bis hin zu XML-Datenbanken. Zum
anderen bestünde die Möglichkeit, die Daten in Dateien zu speichern, aus
denen die benötigten Daten zur Laufzeit ausgelesen werden. Ein Vertreter der letzteren
Variante ist
\jaxb\footnote{http://www.oracle.com/technetwork/articles/javase/index-140168.html}.
\jaxb dient dazu, XML-Schema-Daten an Java-Klassen zu binden und diese aus den
Daten zu erstellen. Im Umkehrschluss können dadurch natürlich auch Java-Klassen
zu XML-Dateien serialisiert werden. \\
Dafür muss die Klasse zunächst mit der Annotation \textit{@XmlRootElement}
versehen werden, die die Klasse an das Wurzel-Element bindet. Jede
\textit{public}-Variable wird zudem automatisch an ein gleich benanntes
XML-Element gebunden. Durch die \textit{@XmlElement}-Annotation kann man aber
auch eine anders benannte Java-Variable an ein XML-Element binden. Über getter-
und setter-Methoden kann man zudem private Variablen binden. Dies ist nützlich,
wenn man vor dem serialisieren bzw. nach dem deserialisieren noch
Modifikationen an den in der Variablen gespeicherten Objekten vornehmen möchte.
Ein Anwendungsfall dafür wäre, wenn ein Objekt-Typ nicht von \jaxb unterstützt
wird. Hier wäre als Beispiel die \textit{Map}-Klasse zu nennen. Diese Klasse
kann innerhalb der Java-Anwendung nützlich sein. Da \jaxb aber nicht von alleine
weiß, wie es Objekte von dieser Klasse (de-)serialisieren soll, wird die
\textit{Map} in einer privaten Variablen gespeichert. In der getter-Methode kann
man dann aus der \textit{Map} beispielsweise ein \textit{List}-Objekt machen.
Entsprechend würde die setter-Methode die \textit{Map} aus einer Liste
erstellen. Für das Serialisieren und Deserialisieren bietet die \jaxb-\api dann
bestimmte Klassen an, die jeweils für eine dieser beiden Aufgaben zuständig
sind. Mittels zwei Klassen kann man also aus einer XML-Datei ein
Java-Objekt erstellen, das alle Daten enthält sowie Änderungen an diesen Daten
im Objekt wieder in der XML-Datei speichern. Das aus der XML-Datei erstellte
Java-Objekt kann dann Methoden anbieten, um diese Daten zu nutzen.
Dadurch kann man auf einer Menge von Daten wie mit einer üblichen Java-Klasse
arbeiten. Bei Datenbanken müsste man dafür verschiedene
Datenbank-Anfragen(\textit{Queries}) erstellen und diese erst in einer
Java-Klasse kapseln. Für das reine Auslesen und Bearbeiten von XML-Dateien, z.B.
durch \textit{\ac{SAX}}\footnote{http://www.saxproject.org/}, müsste man
ebenfalls erst einen komplexeren Weg gehen. Bei \textit{\ac{SAX}} müsste man
beispielsweise, zusätzlich zur Java-Repräsentation der Daten, erst einen
\textit{ContentHandler} schreiben, der verschiedene Ereignisse beim Einlesen
einer XML-Datei untersucht und deren Inhalte wie gewünscht in Java-Objekte
umsetzt. Dies geschieht aber bei \jaxb bereits automatisch.
\\
Einerseits haben wir uns aufgrund dieser einfacheren Handhabung für \jaxb
entschieden. Andererseits wird \jaxb auch in \masp zum Persistieren des
Kontextmodells genutzt. So können wir durch den Einsatz von \jaxb eine
technologische Konsistenz erhalten.

\mysubsection{JUnit}
\label{real:subsec:junit}
Um unsere Realisierung zu testen, haben wir uns für das
JUnit-Framework\footnote{http://www.junit.org/} entschieden. Es ermöglicht das
einfache Testen von unterschiedlich großen Einheiten bzw. Komponenten eines
Systems. So können JUnit-Tests sowohl für einzelne Klassen, als auch für
größere, aus mehreren Klassen zusammengesetzte Komponenten geschrieben werden.
\\
Das JUnit-Framework bietet dabei eine einfache Lösung, um Testfälle zu
schreiben. Es reicht aus, eine einfache Java-Klasse zu implementieren. In dieser
Klasse muss dann für jeden Testfall eine Methode geschrieben werden. Damit das
Framework diese Methoden auch als Testfall erkennt, müssen diese mit der
Annotation \textit{@Test} versehen werden. Das Framework ruft nun alle so
annotierten Methoden in der Reihenfolge ihres Auftretens in der Klasse auf.
Dadurch ist es auch möglich, Hilfsmethoden zu schreiben, die beispielsweise von
mehreren Testfällen benutzt werden. Solche Hilfsmethoden werden nicht mit
Annotationen versehen und dadurch vom Framework beim Aufrufen der Testfälle
nicht beachtet.
\\
Zudem bietet das JUnit-Framework auch eigene Möglichkeiten, wiederkehrende
Hilfsmethoden ohne expliziten Aufruf in den Testfällen zu verwenden. So wird
eine Methode, die mit \textit{@Before} annotiert ist, vor jedem Testfall
aufgerufen. Wir werden eine so annotierte Methode im Folgenden startUp-Methode
nennen. In dieser Methode kann man dann allgemeine Vorbedingungen für alle
Testfälle erstellen. Zum Beispiel könnte eine Datenbank mit initialen Werten
gefüllt werden. Analog zur startUp-Methode kann man auch eine Methode mit
\textit{@After} annotieren. Diese wird nach jedem Testfall aufgerufen und dient
dazu, den Zustand des Systems wieder so weit auf den Ausgangszustand zu bringen,
dass keine unerwünschten Nebeneffekte in folgenden Testfällen auftreten. So
könnte man hier die Datenbank wieder komplett löschen, damit im Testfall neu
erstellte Datensätze nicht mehr erhalten bleiben. Diese Methode werden wir im
Folgenden tearDown-Methode nennen.